Within 3GPP, in UTRAN or LTE macro wireless networks (radio access networks or RANs), a femtocell or Home Node B (HNB in a 3G network or H(e)NB in an LTE network) may perform the function of a Node B as an access node to the network but is optimized for use in a home or office (enterprise). Individual access points (HNBs or H(e)NBs are installed individually by end users, without strict supervision of the Mobile Network Operator (MNO).
In any wireless communications network, maintaining an up-to-date neighbor cell relationship is a difficult task for network operators, which requires detailed planning and exact implementation according to the plan. If there is any ambiguity or outdated information about neighbour cell relationships, a problem arises in that the erroneous information may be used in the access nodes of the network. This in turn can lead to inaccurate information being provided to mobile terminals subscribed to the network, for example causing handover from one access node to another to fail. The neighbour cell relationship between access nodes needs to be provisioned at start-up to each access node and kept up to date so as to reflect the actual situation in the network. However, even when the network has been planned in detail and implemented exactly, errors during installation may still occur. The configuration, planning and installation effort of a wireless network should be reduced to a minimum in order to save time and money.
In the cases where a Home Node B network is involved, maintenance of an up-to-date neighbour cell relationship is further complicated by the fact that for a HNB, the node can be switched off and on by the user and therefore availability of related cell is not guaranteed. The basic principle behind uncoordinated deployment of H(e)NBs is that the H(e)NBs, while being part of the MNO's network are installed at the customers' premises in such a way that their deployment does not involve any kind of detailed network planning. Therefore the exact network topology is not known to the operator. This makes it difficult for the operator to become aware of neighbour relationships between the individual access nodes and in turn causes problems in creating cell reselection and handover procedures.
Since the network does not know the exact whereabouts of the H(e)NB, it cannot set up the neighbour list for each of the H(e)NBs; i.e., the list of potential targets for cell reselection (in idle mode) and for handover (in dedicated mode). The knowledge of the actual neighbour nodes of each individual H(e)NB is however necessary, as the mobile subscriber stations or user equipments (UEs) which are camping on a particular cell (in the case of 3G networks) have to be explicitly provided with a list of neighbouring access nodes whose signals these UEs have to measure and take into account in cell reselection procedures. This is also the case in the connected mode, where the UEs are provided with the list of neighbours to measure and report.
In coordinated deployments of macro networks, neighbour relationships between access nodes ((e)Node Bs) are determined using network planning and field measurements, since the MNO is fully aware of the physical location of each access node and can determine the exact neighbours of each access node. This information is then used to create a neighbour list (for 3G networks) or a neighbour relation table (For LTE ANR usage) for each access node in the network. Whenever a new node is added, the MNO can assess its impact on the existing network and possibly update the neighbour lists in the affected nodes.
In uncoordinated deployments, existing solutions for establishing neighbour relationships between H(e)NBs are based on the MNO estimating the neighbours of any given access node, which has a very limited degree of accuracy. Each of the users of the mobile network are supposed to provide their home addresses to the MNO when they subscribe to the network and each HNB is expected to provide information about the strongest detected macro node of the macro network it belongs to (in HNBAP HNB REGISTER REQUEST, as defined in 3GPP TS 25.469). These data can be used by the MNO to derive a tentative neighbour list for that node. As the configuration of H(e)NB parameters is performed automatically at the start-up phase, each H(e)NB receives a generic set of parameters from an Auto Configuration Server (ACS) so in theory there will be a general neighbour list valid for a certain area and all H(e)NBs supposedly located in this area will share the same list. However, updating this list is problematic, as the H(e)NB may be required to reboot or at least actively contact the ACS to obtain a new set of parameters including, the NCL.
Another possible solution to populating the neighbour list in UTRAN and LTE networks is to enable Detected Set Reporting (DSR) by the UEs, where the UEs will report unsolicited neighbours that fulfill the reporting criteria. The downside of this is that it takes a long time to detect all possible neighbours. This means that at the initial stage, when the neighbour list is not complete, there could be a large number of handover failures.
The general problem of establishing and maintaining neighbour lists between H(e)NBs is illustrated in FIG. 1, which shows 10 H(e)NBs (H(e)NB 1 . . . 10) installed in 10 rooms (rooms 1 . . . 10), respectively on one floor of an office (enterprise) and able to access two macro networks Macro “A” and Macro “B”.
In order to enable the MNO to correctly configure the neighbour lists, the subscriber (in this case the enterprise) not only needs to inform the MNO about which H(e)NB is placed in which room but also about which rooms are the neighbouring rooms, as well as the H(e)NB identities and the position in the room where each H(e)NB is located. Even if there are GPS coordinates available for each of the H(e)NBs 1 . . . 10, the problem remains that the H(e)NBs may not be placed at the locations where they should have been according to planning, for example if two devices become confused with each other. FIG. 2 shows an exemplary neighbour list for three of the H(e)NBs H(e)NB 1, H(e)NB 2 and H(e)NB 10 located in rooms 1, 2 and 10, respectively. Including these H(e)NBs in the neighbour list as distributed by the management system of the network is certainly possible but requires a large effort and very detailed planning. However, these lists can only ever be an estimate and there is no guarantee that they reflect the reality of the situation. For example, if the subscriber had given the MNO wrong information about room location and room 6 was not in fact located opposite to room 1 across the corridor from it but rather on the same side of the corridor next to room 5, the information in the neighbour list of H(e)NBs would be completely wrong.
There is no existing method for a neighbour list of access nodes in a Femto or H(e)NB network to be established and maintained so that the list contains up-to-date information as to which access nodes are neighbours to each other.
It is thus an object of the present invention to overcome the above-mentioned drawbacks and allow neighbour relations to be established and maintained between H(e)NBs so that they are up-to-date, thereby facilitating successful handovers and avoiding failed handover situations.